wafer.space Community - pure digital, no hard macros, no SRAM.

12:32 a.m.

Ok, so it's just a big design then. Can you tell which rule it's stuck on by looking at the current log file?

2025-12-01 13:25:53 +0000: Memory Usage (1206676K) : Starting deriving base layers.
2025-12-01 13:28:27 +0000: Memory Usage (2314588K) : Construct connectivity for the design.
2025-12-01 13:28:28 +0000: Memory Usage (2314588K) : Connectivity rules enabled, Netlist object will be generated.
Chip' - Stage 68 - Design Rule Check (KLayout) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━━━ 67/77 11:58:20

Is it thrashing? How's your memory usage?

57.1 GiB free memory

12:34 a.m.

4.17GiB used by klayout (edited)

12:34 a.m.

If you do a find openlane/<block>/runs/<timestamp> you should see a lot of files generated at each step. If you look in the directory for klayout-drc (not sure of the name), there should be a real time log showing how much time was spent on each rule. Depending on the output buffering, you may be able to tell which rule is currently being checked.

message.txt

8.16 KB

@Lofty So that looks like it's been running for about 2 min. Maybe the step after that is where it's stuck. Might be helpful to look at the log after it completes. Is there a openlane configuration variable to do deep vs flat drc? All the configuration variables (including defaults) are in the openlane/<block>/runs/<timestamp>/resolved.json file.

bailey

@Lofty So that looks like it's been running for about 2 min. Maybe the step after that is where it's stuck. Might be helpful to look at the log after it completes. Is there a openlane configuration variable to do deep vs flat drc? All the configuration variables (including defaults) are in the openlane/<block>/runs/<timestamp>/resolved.json file.

(I killed the run, because I didn't have any reason to believe it would complete after another twelve hours of runtime)

@Lofty do you have any old runs still around in a different timestamp directory that completed?

not anymore, no

bailey

@Lofty So that looks like it's been running for about 2 min. Maybe the step after that is where it's stuck. Might be helpful to look at the log after it completes. Is there a openlane configuration variable to do deep vs flat drc? All the configuration variables (including defaults) are in the openlane/<block>/runs/<timestamp>/resolved.json file.

also, I should maybe point out the timezone there. it wasn't running for 2 minutes.

@Lofty Not sure what you mean about timezone. Start time 2025-12-01 13:24:36 Last enty 2025-12-01 13:25:41

bailey

@Lofty Not sure what you mean about timezone. Start time 2025-12-01 13:24:36 Last enty 2025-12-01 13:25:41

yes, and it is currently 2025-12-02 01:40

1

Ok, either the last few log entries were buffered or it prints after completion and it was stuck somewhere. Probably need a complete log to know for sure.

bailey

Ok, either the last few log entries were buffered or it prints after completion and it was stuck somewhere. Probably need a complete log to know for sure.

that was the complete log

Sorry, I mean a log file after klayout-drc has completely finished.

like, even in stdout there were no rules mentioned; I genuinely don't think it made it far enough to get stuck on a rule

You may be correct. I have seen log files that are piped or tee'd get buffered though.

Are you on macOS? I've been running into the same issue

Trevor Peyton

Are you on macOS? I've been running into the same issue

WSL

10:56 a.m.

well, I re-ran the flow overnight, and...it's stuck on klayout again

@Lofty Did you came this far?

11:52 a.m.

Leo Moser (mole99)

Click to see attachment 🖼️

yes.

11:52 a.m.

and then it hangs.

Alright, let's wait for a while.

Leo Moser (mole99)

Click to see attachment 🖼️

It's been an hour. Any luck?

It's still generating the netlist object. For KianV this took 1-2h iirc. Since your design is all combinatorial I would assume it to take even longer.

12:57 p.m.

However, you can try something else on your end: Go to gf180mcu/gf180mcuD/libs.tech/librelane and open config.tcl. Set conn_drc to false: dict set ::env(KLAYOUT_DRC_OPTIONS) conn_drc false

12:59 p.m.

This will skip generating the netlist object. But this also means KLayout needs to consider the worst case for connectivity rules. Still, worth a try.

Leo Moser (mole99)

This will skip generating the netlist object. But this also means KLayout needs to consider the worst case for connectivity rules. Still, worth a try.

okay, we have rules being executed now; this is great

1

Leo Moser (mole99)

It's still generating the netlist object. For KianV this took 1-2h iirc. Since your design is all combinatorial I would assume it to take even longer.

FYI mine took 8+ hours and it didn't change from that step... I'll try that option (edited)

Trevor Peyton

FYI mine took 8+ hours and it didn't change from that step... I'll try that option (edited)

You can try disabling conn_drc as well. But then you might get false positive DRC errors.

[15:53:43] VERBOSE  Running 'Checker.KLayoutDRC' at 'librelane/runs/RUN_2025-12-02_01-03-17/65-checker-klayoutdrc'…                                                  step.py:1138
[15:53:43] ERROR    16 KLayout DRC errors found. - deferred                                                                                                        checker.py:124

urgh

Nice, we can work with that.

um, they seem to all be NW.2b_MV violations?

4:02 p.m.

"Min. Nwell Space (Outside DNWELL) [Different potential]"

As expected, since Klayout does not have any connectivity information it needs to assume the worse.

4:04 p.m.

Can you open the violations in the KLayout Marker Browser and send me a screenshot where they are located? (edited)

um, where's the marker database file to open? (edited)

4:09 p.m.

I think I found it, but it's giving me stuff like this

4:09 p.m.

Leo Moser (mole99)

Can you open the violations in the KLayout Marker Browser and send me a screenshot where they are located? (edited)

^

Is this with just the Nwell layer enabled?

@lofty, turn on only nwel and then set the display levels to 0 - 20 (or hit the + key until all the cell frames disappear)

https://fieldprogrammable.gay/files/1be1a3b6-04d2-4074-a2b8-3acb36408573.png um, like this?

4:46 p.m.

it seems like the DRC rules are generating pairs of errors for this

4:46 p.m.

so there are only like 8 actual conflicts?

4:49 p.m.

https://fieldprogrammable.gay/files/a664e04a-50dd-4b95-8ba4-4e808309e917.png https://fieldprogrammable.gay/files/8fe28588-7e40-46bb-a3f7-9886b62a5712.png https://fieldprogrammable.gay/files/95d36260-cf52-4a45-963f-7eefcda28188.png https://fieldprogrammable.gay/files/cd37610a-6153-4105-a78a-e879a1effaee.png (edited)

4:49 p.m.

https://fieldprogrammable.gay/files/25dab0b6-a805-45d3-9dce-f6da62b0346f.png https://fieldprogrammable.gay/files/af3b0b74-f785-4add-8416-b2ea3e45f585.png https://fieldprogrammable.gay/files/db6629bf-3154-4667-848e-081c97086263.png https://fieldprogrammable.gay/files/8c8630f9-3ed3-40a4-9bb0-06d2384e10fa.png

4:50 p.m.

cc @bailey @Leo Moser (mole99)

@Lofty Sorry, I was afk. The next step is to make sure all devices use the "Dualgate" layer. These are the thick oxide transistors for 5V/6V. This should be the case anyways if you use the foundry provided I/O cells and standard cells. If so, it means we can actually use rule NW.2a (equi-potential). Now, just take a measurement between the edges and check that the spacing is >= 0.74um. I'll do the same before adding your design to the shuttle, but this way you can already be sure these are false positives :)

6:59 p.m.

FYI KLayout was not stuck, it just took a looong time:

6:59 p.m.

7:00 p.m.

This will make for a good test case for Matthias.

8:43 p.m.

Almost 9 hours, but we're done. The magic DRC errors are CO.3 and can be ignored.

8:44 p.m.

@Lofty Your design is DRC clean

Leo Moser (mole99)

@Lofty Your design is DRC clean

hurray; too bad that GDS has hold violations and I have spent the past several hours building a new GDS >.<

8:54 p.m.

all the same, I don't think I have much to worry about there.

8:56 p.m.

maybe I really do need a CPU upgrade though, if it takes me 12 hours to fail to achieve what you can complete in 9...

At least you know that there isn't anything special DRC-wise about your design. So the next iteration will very likely also be DRC clean. I'm using a Ryzen 9 9900X and I'm running it natively on Linux. It may be that the emulation through WSL2 may cause you to lose some performance.

well, now I have very slow antenna checking ^^;

4:30 p.m.

it's stuck on 2025-12-05 15:21:23 +0000: Memory Usage (3550244K) : Executing rule ANT.16_i_ANT.5

You can jump to the latest tag of the PDK: https://github.com/wafer-space/gf180mcu/releases/tag/1.4.3 There have been two more changes that should speed up the antenna check, however, don't expect miracles.

now I'm getting what seems to be an LVS failure?

11:46 p.m.

um, @bailey you seem to be the person to talk to about LVS?

11:47 p.m.

Circuit 1 contains 137698 devices, Circuit 2 contains 140300 devices. *** MISMATCH ***
Circuit 1 contains 133045 nets,    Circuit 2 contains 138947 nets. *** MISMATCH ***

11:49 p.m.

oh. am I running into Magic issues because I have autoname on?

Lofty

oh. am I running into Magic issues because I have autoname on?

@Lofty I have seen errors due to autoname. I've used klayout to manually removed them from the gds without having to rerun. From the limited information above, I'm guessing that there are unconnected power rails for some standard cell rows. Most probably between or at the edges where there's not enough room to intersect with power rails. If you share the cell list from the lvs.report that precedes the mismatch counts above, I might be able to suggest something else.

netgen-lvs.log

153.62 KB

@Lofty this one lvs.netgen.rpt has more information.

lvs.netgen.rpt

9.45 MB

... and how about the lvs_config.json file. Looks like the standard cell spice may not be loaded. Do you know what command is being used to run LVS?

bailey

... and how about the lvs_config.json file. Looks like the standard cell spice may not be loaded. Do you know what command is being used to run LVS?

um, I don't have a file by that name?

@Lofty ok. I'm not yet familiar with the wafer.space LVS setup. Is it run as part of precheck or a github action or is there a command to run LVS locally?

it's librelane

1:05 a.m.

https://github.com/librelane/librelane/blob/main/librelane/scripts/netgen/setup.tcl

1:06 a.m.

https://github.com/librelane/librelane/blob/main/librelane/steps/netgen.py#L127 (edited)

@Lofty thanks, that explains a lot. Looks like the verilog and layout are out of sync. I'm seeing mismatches in standard cell counts that should not happen.

gf180mcu_fd_sc_mcu9t5v0__oai21_1 (12908)   |gf180mcu_fd_sc_mcu9t5v0__oai21_1 (13137) *
gf180mcu_fd_sc_mcu9t5v0__mux2_1 (10908)    |gf180mcu_fd_sc_mcu9t5v0__mux2_1 (10942) **

The layout is the abstract extracted spice runs/eco/29-magic-spiceextraction/chip_top.spice, but unfortunately, I can't find what verilog netlist is being used. I'll create a PR that records that file in the log file.

bailey

@Lofty thanks, that explains a lot. Looks like the verilog and layout are out of sync. I'm seeing mismatches in standard cell counts that should not happen.

gf180mcu_fd_sc_mcu9t5v0__oai21_1 (12908)   |gf180mcu_fd_sc_mcu9t5v0__oai21_1 (13137) *
gf180mcu_fd_sc_mcu9t5v0__mux2_1 (10908)    |gf180mcu_fd_sc_mcu9t5v0__mux2_1 (10942) **

The layout is the abstract extracted spice runs/eco/29-magic-spiceextraction/chip_top.spice, but unfortunately, I can't find what verilog netlist is being used. I'll create a PR that records that file in the log file.

I did eco in some hold buffers, but...they should be in there? Hmm

Here's the PR with the change. https://github.com/librelane/librelane/pull/831 If you wanted to make the change locally, you could verify whether or not the expected top level verilog netlist is being used.

Display top verilog file name in LVS log. by d-m-bailey · Pull Req...

Currently, the top level verilog file name is not displayed in the netgen log. Here&#39;s a sample Reading SPICE netlist file &#39;/home/&lt;user&gt;/gf180mcu-chess/gf180mcu/gf180mc...

Lofty

Circuit 1 contains 137698 devices, Circuit 2 contains 140300 devices. *** MISMATCH ***
Circuit 1 contains 133045 nets,    Circuit 2 contains 138947 nets. *** MISMATCH ***

Circuit 1 contains 140296 devices, Circuit 2 contains 140296 devices.
Circuit 1 contains 138946 nets,    Circuit 2 contains 138946 nets.

Final result:
Circuits match uniquely.

the issue is indeed Magic; this is using 8.3.578 which includes the 512-character maximum name length fix (edited)

1

7:07 a.m.

(@Leo Moser (mole99) maybe the flake.nix should be updated?)

Lofty

(@Leo Moser (mole99) maybe the flake.nix should be updated?)

I'm on it!